Skip to content

Asynchronous logger & Improved debug logging for 'E' Events - #272

Open
Unshown wants to merge 8 commits into
BeamMP:masterfrom
rigged-development:feature/improved-logging
Open

Asynchronous logger & Improved debug logging for 'E' Events#272
Unshown wants to merge 8 commits into
BeamMP:masterfrom
rigged-development:feature/improved-logging

Conversation

@Unshown

@Unshown Unshown commented Aug 24, 2026

Copy link
Copy Markdown

1. Refactor logger to run asynchronously to prevent event loop blocking
Previously, the logger opened, wrote to, and closed Launcher.log synchronously on every single log call. Under heavy network traffic, this file I/O was stalling the main networking threads, contributing to dropped connections when too many events were received at once.

This commit moves the logger to a dedicated background thread.

  • Added a std::queue<std::string> and a std::condition_variable to handle log dispatching.
  • Log calls (info, debug, etc.) now instantly push their messages to the queue and return immediately, freeing up the network threads.
  • Added a lightweight Utils::ToString helper in Utils.h (mirroring the existing ToWString) to convert wide strings into standard UTF-8 strings before pushing them into the new logger queue.

This significantly improves launcher performance under heavy load without changing the visual log output.

2. Add debug logging for Lua custom events ('E' packets)
Added targeted debug logging in GlobalHandler.cpp for both incoming and outgoing custom events (C == 'E').

Previously, it was difficult to tell when custom events were causing network saturation. This change logs the total size and name of all custom events passing through the launcher. To prevent console spam, the logic intelligently strips out the JSON payload body (truncating at the first { or [) so only the clean event name and byte size are printed.

Note: Because the logger was moved to an asynchronous background, adding this detailed logging is completely safe. It will not block the main network loop or cause connection drops, even if a server mod aggressively spams thousands of events per second.

This should significantly help server owners and mod developers quickly identify network event spam and help find optimization measures.


By creating this pull request, I understand that code that is AI generated or otherwise automatically generated may be rejected without further discussion.
I declare that I fully understand all code I pushed into this PR, and wrote all this code myself and own the rights to this code.

Previously, the logger opened, wrote to, and closed `Launcher.log` synchronously on every single log call. Under heavy network traffic, this file I/O was stalling the main networking threads, contributing to dropped connections when too many events were received at once.
This commit moves the logger to a dedicated background thread.
- Added a `std::queue<std::string>` and a `std::condition_variable` to handle log dispatching.
- Log calls (`info`, `debug`, etc.) now instantly push their messages to the queue and return immediately, freeing up the network threads.
- Added a lightweight `Utils::ToString` helper in `Utils.h` (mirroring the existing `ToWString`) to convert wide strings into standard UTF-8 strings before pushing them into the new logger queue.
This significantly improves launcher performance under heavy load without changing the visual log output.
Added targeted debug logging in `GlobalHandler.cpp` for both incoming and outgoing custom events (`C == 'E'`).

Previously, it was difficult to tell when custom events were causing network saturation. This change logs the total size and name of all custom events passing through the launcher. To prevent console spam, the logic intelligently strips out the JSON payload body (truncating at the first `{` or `[`) so only the clean event name and byte size are printed.

Note: Because the logger was moved to an asynchronous background queue in the previous commit, adding this detailed logging is completely safe. It will not block the main network loop or cause connection drops, even if a server mod aggressively spams thousands of events per second.

This should significantly help server owners and mod developers quickly identify network bottlenecks.
Comment thread src/Logger.cpp
Comment thread src/Logger.cpp Outdated
Comment thread src/Logger.cpp
Comment thread src/Network/GlobalHandler.cpp Outdated
@Unshown
Unshown requested a review from WiserTixx August 26, 2026 15:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants